As the internet has grow both in size and functionality, more and more services have been made available to internet users. Online shopping, banking, email and other web-based applications are used every day by millions around the world. Such applications, however, require a more sophisticated architecture than Hypertext Transfer Protocol (HTTP) was originally designed to provide. For example, HTTP is a stateless protocol. Thus, when a user connects to a web server, the web server responds with a reply, but does not maintain a memory the transaction and thus, if the same user sent another request to the same web server, the web server would not relate the new request to the previous one. Many web applications, however, require the server to remember not only the user's previous requests, but also the results of the transaction. For example, if a user was browsing an online bookstore and had selected one book to purchase but wanted to continue shopping, the user would want the server to remember which books the user had already looked at and which ones had been marked for purchase. One solution to this problem is to use cookies.
Cookies are small text files stored locally on the client's computer system and are used to identify the client to the server. Typically, a unique identifier (e.g. a string of numbers and/or characters) is assigned to the client. Then, when the client sends a request to the web server, the request includes the unique ID. The web server can then associate any previously stored information related to that user (i.e. session state information) and use the session state information to provide a more customized experience for the client. Session state information is used in a variety of situations where it is advantageous to dynamically generate a web page requested by a user. Applications such as online banking and online shopping necessitate the creation of web pages suited specifically for the user and for that particular session. Solutions for dynamically creating web pages include Active Server Pages (ASP), ASP.NET, PHP: Hypertext Preprocessor (PHP), Ruby on Rails, and others.
In general, dynamic web page generators, such as those mentioned above, are incompatible with each other. For instance, if a client sent a PHP request to a web server that was running ASP, the ASP web page generator would not be able to create the web page because ASP would not understand the request. Similarly, if a client sent an ASP request to a server running ASP.NET, the ASP.NET web page generator would be unable to generate the web page because of incompatibility between the systems. This can create large problems for corporations that have invested large amounts of time and money in older solutions such as ASP and now desire to switch to newer solutions such as ASP.NET. Solutions such as ASP, for example, lack the ability to scale onto multiple web servers or be managed from a single point.
Attempts have been made to reconcile the incompatibility between different web page generators. For example, in situations where a portion of the web server's content is available via ASP and another portion is available via ASP.NET, a user may (without knowing it) browse to both portions of content. Thus, in such cases, the ASP web page generator would need to know what information had been processed by the ASP.NET web page generator and vice versa. Solutions for sharing session state information between dynamic web page generators typically include major changes to the client's computer system and/or the client's web browser. Other solutions include, for example, receiving a request for an ASP-generated web page, processing the request with the ASP web page generator, storing the session information into an external storage, and then pointing the other web page generator (e.g. ASP.NET) to the external storage. Such solutions are often intrusive and/or cumbersome.